Motivation and Context

Was testing our BDD implementation against the updated service models with BDD traits. Found two bugs that impacteddynamodb and s3control.

Description

DynamoDB endpoint resolver

DynamoDB's BDD exercises two codegen patterns that no other service uses, and both
produced uncompilable Rust:

1. stringEquals(multipartTemplate, optionalRef) with a {Var#attr} interpolation on an
   assigned variable (condition 8). The template's dynamic-part path was hard-coded to the
   tree-mode generator and lost BDD's Option-unwrap tracking; the comparison wrapper
   inherited Borrowed ownership, producing &mut Option<&String> instead of &mut Option<String>.
2. parseArn(FirstArn) where FirstArn = getAttr(ResourceArnList, "[0]") (conditions
   19/20). The list-index assignment eagerly cloned (Option<String>), severing the lifetime
   chain back to the parameter; parseArn then produced Arn<'closure> that couldn't fit the
   context's outer-lifetime slot

Fix (LiteralGenerator.kt, BddExpressionGenerator.kt, EndpointBddGenerator.kt):

• LiteralGenerator now accepts an exprGenerator callback so BDD-mode template dynamic
  parts retain Option-unwrap tracking; the inner String-typed parameter case renders as
  name.as_deref().unwrap_or_default().
• visitStringEquals switches to Ownership.Owned when wrapping a Literal in &mut Some(...), so multipart templates produce an owned String.
• A new isBorrowedStr flag on AnnotatedRef marks SSA variables whose assignment is a
  borrow-preserving chain (Reference/GetAttr rooted at a parameter). Those context fields
  are emitted as Option<&'a str>, and the assignment uses .first().map(|s| s.as_str())
  rather than .first().cloned() ... .into(). The parameter → SSA variable → parseArn
  result lifetime chain is preserved end-to-end.

S3 Control parameter / SSA-variable name collision

S3 Control's BDD declares parameter ResourceArn and SSA variable resourceArn, distinct
identifiers in Smithy that both rust-name to resource_arn. Per-condition closures emit
let resource_arn = &mut context.resource_arn;, which
shadows the top-level let resource_arn = &params.resource_arn;. Any condition body that referenced the parameter (e.g. parseArn(ResourceArn)) saw the uninitialized context variable instead.

Fix (EndpointBddGenerator.kt, BddExpressionGenerator.kt, Util.kt,
ExpressionGenerator.kt):

• AnnotatedRefs.from detects when an SSA variable's rust-name collides with an existing
  entry and disambiguates by appending _ctx_N. For S3 Control: resourceArn
  becomes resource_arn_ctx_1 the parameter keeps the unmodified resource_arn.
• A nameByOriginal rename map is threaded through AnnotatedRefs and Context, and every
  code-emission site (BDD condition closures and the tree-mode ExpressionGenerator used
  for endpoint result construction) resolves identifiers via refs.resolveName(id) so the
  disambiguated name propagates consistently.

Testing

Tested that the models built correctly and that their endpoint tests pass. Updated thedynamodb and s3-control models in the repo to have endpointBdd traits since those were the two that caused issues.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.